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AN ELECTRONIC BILL PAYMENT SYSTEM WITH ACCOUNT RANGING, U.S. 

Application Serial No. , filed , entitled 

AN ELECTRONIC BILL PAYMENT SYSTEM WITH ACCOUNT NUMBER SCHEMING 
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FIELD OF THE INVENTION 

The present invention relates to electronic commerce. 
More particularly, the present invention relates to an 
improved electronic bill payment system. 

15 
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BACKGROUND OF THE INVENTION 

It has been common for many years for consumers to pay 
bills by way of a personal check written by the consumer to 
the order of an entity and delivered to that entity by mail or 
5 in person. With the proliferation of computers interconnected 

to computer networks, particularly the Internet, consumers can 
now pay bills electronically. However until recently it was 
not possible for a consumer, using a computer terminal, to 
interact with a single payment system capable of paying all 
10 the consumer's bills whether by electronic means or by a paper 



check. Such a system now exists in the form of a consolidated 



bill payment system as described by Kight , et al . in U.S. 



Patent 



No. 



5,383,113, 



ent i t led SYSTEM AND METHOD FOR 



ELECTRONICALLY PROVIDING CUSTOMER SERVICES INCLUDING PAYMENT 



15 



OF BILLS, FINANCIAL ANALYSIS AND LOANS. 



Although the consolidated bill payment system described 



by Kight , et al . significantly advanced the state of the art, 



it did not focus on several problems which may arise in 



implementing a consolidated bill payment system capable of 



20 



automatically paying consumer bills to merchants. 
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A typical state of the art electronic bill payment 
system is established by a financial institution or third 
party to provide subscribing customers with the capability 
to electronically pay registered merchants. Present day 
5 electronic bill payment systems operate in an integrated 

manner to collect payment requests electronically from 
consumers, process those requests to render them suitable 
for payment, and then pay the registered merchants, i.e., 
merchants listed in the system database. Hence, using 

10 present day systems, each has to establish relationships 

with both customers and merchants. 

Developing and implementing a bill payment system has 
significant costs. First, a relationship has to be 
established with each merchant. Furthermore, special 

15 formatting requirements, and other rules and procedures 

required by each merchant for presenting payment data in a 
form the merchant system can process automatically must be 
determined and complied with. One of the features most 
desirable in any consolidated electronic bill payment system 

2 0 is that a consumer be allowed to pay any merchant to which 
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the consumer owes a bill. Ultimately, this means that each 
conventional bill payment system may have hundreds of 
thousands of merchants in a database. Each bill payment 
entity must establish relationships with these merchants and 
5 comply with their special rules and procedures for the 

transfer of payment data. This is an expensive and time 
consuming process. Thus, it would be beneficial to provide 
a way to reduce the time and expense which must now be spent 
by every bill payment entity to implement a consolidated 

10 bill payment system. 

Another problem is that consumers or data entry 
personnel sometimes make mistakes in entering payment data 
required by the bill payment system. Such a case arises when 
a consumer's account number with a merchant is incorrectly 

15 entered. The payment system must submit a correct account 

number to the merchant who will use this account number to 
associate the payment with the consumer. Thus, a technique 
is needed to validate the submitted consumer's account 
number . 
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A data entry person may also enter payment data which 
incorrectly specifies the merchant's name or parts of the 
merchant's address. It has been found that merchant 
information such as the merchant name, address, zip code are 
5 typically mangled at the data entry stage. It has been 

further observed that errors will often be made upon entry 
of the zip code. The merchant's name, address, and zip code 
is typically required by the payment system in order to, for 
example, retrieve merchant records from the merchant 

10 database. If this data is incorrect, the payment system may 

be unable to retrieve the correct merchant's record for 
processing a payment. Thus, a technique is needed to 
correctly identify a merchant record notwithstanding the 
submission of erroneous merchant data. 

15 A consolidated bill payment system must also have the 

capability to properly remit payments to the same merchant 
at more than one remittance center. Commonly a large 
commercial merchant , (e.g. , shoe company, Sears) will have 
several remittance centers distributed geographically so 

20 that customers can submit bills to a center within their 
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location. Thus, a technique is required to ensure that 
consumer payments are remitted to the proper one of multiple 
remittance centers associated with the same. 

Advantageously, a consolidated payment system must also 
5 be able to handle the different processing formats and 

requirements of numerous separate merchant accounting 
systems. For example, each merchant's account system may 
require payment information, such as consumer account 
numbers, in a format different than that submitted by the 
10 consumer. For example, many merchant accounting systems 



will only accept an account number with some portion of a 



consumer's last name or the consumer's zip code appended to 



the end of the account number presented by the customer. 



A merchant account system may even require an altered 



15 



consumer account number which uniquely identifies the 



consumer. For example, two consumers, e.g 



spouses, may 



have identical account numbers, but the merchant accounting 



system may designate the account of each consumer uniquely, 



such as by combining the account number with the prospective 



20 



customer's name. Additionally, it is not unusual for a 
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merchant to have different account numbers for a single 
customer. For example, an account number on an invoice 
which goes out electronically may be different from an 
account number for the same customer which goes out as a 
5 paper transaction. 

Thus, a consolidated bill payment system must be able 
to handle the various formats required by the merchant 
accounting system of each merchant. Accordingly, a 
technique is required to transform payment data received 
10 from the consumer into a form compatible with a merchant's 

accounting system . 



Objectives of the Invention 

Accordingly, it is an object of the present invention 
15 to provide an improved technique for automatically paying 

bills to any merchant on behalf of consumers. 

It is a further object of the present invention to 
provide a technique which allows individual bill payment 
entities to implement consolidated bill payment system with 
2 0 greater efficiency. 
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It is a further object of the present invention to 
provide a technique for correcting erroneous bill payment 
data received from customers. In particular, it is an 
object of the present invention to correctly identify a 
merchant record based on received information which may 
include erroneous data. 

It is still a further object of the present invention 
to provide a technique for furnishing payment information, 
including a payor's account number with a merchant, in a 
format acceptable to a particular merchant's accounting 
system. 

It is another object of the present invention to 
provide a technique for validating a consumer's account 
number with a merchant . 

It is another object of the present invention to 
provide a technique for ensuring payments are remitted to 
the proper remittance center. 

Additional objects, advantages, novel features of the 
present invention will become apparent to those skilled in 
the art from this disclosure, including the following 
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detailed description, as well as by practice of the 
invention. While the invention is described below with 
reference to preferred embodiment (s) , it should be 
understood that the invention is not limited thereto. Those 
5 of ordinary skill in the art having access to the teachings 

herein will recognize additional implementations, 
modifications, and embodiments, as well as other fields of 
use, which are within the scope of the invention as 
disclosed and claimed herein and with respect to which the 
10 invention could be of significant utility. 



SUMMARY OF THE INVENTION 

In order to solve the limitation of present art 
electronic bill payment systems, the present invention 

15 provides a method and apparatus for electronically 

processing bill payment requests where respective sets of 
payment requests are received electronically from a 
plurality of independent sources, each set of payment 
requests corresponding to an associated set of payors 

20 requesting payments to a plurality of payees. The payment 
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requests are processed at a single remittance processing 
system having a database including payee information for 
each of the plurality of payees to generate payment 
directions for paying the plurality of payees in accordance 
5 with the processed payment requests. 

A source may include any computer or network of 
computers capable of collecting payment requests from 
consumers, and may be, for example, a CheckFree processing 
center, a financial institution, or some other payment 

10 processing center. Typically a payment request would be a 

record containing whatever information is needed to process 
a particular payment. 

Beneficially, the sets of payment requests from payors 
are sent from the sources to the bill payment system as 

15 batch files. Preferably, the bill payment system can 

normalize batch files received from the sources to 
correspond to a single normalized format. 

In yet another aspect of the present invention, each of 
the received payment requests includes payor payment 

2 0 information, and the payment information other than a 
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received zip code is processed to identify an eleven digit 
zip code for the payee to be paid. The database is then 
accessed by the eleven digit zip code to locate payee 
information on the payee to be paid. 

In a still further aspect of the present invention, a 
payee has a plurality of payment remittance centers and a 
payment request includes information identifying a payor 
account number with the payee. The account number is 
processed to select one of the plurality remittance centers 
and payment is directed to the selected remittance center 
for the payee . 

In a further aspect of the present invention, each of 
the payment requests includes a payor's account number with 
a p a yee. Alteration rules are stored corresponding to a 
payee account number format and one of the received account 
numbers is transformed into an altered account number 
according to the alteration rules. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a system overview of an automated bill 
payment system in accordance with the present invention. 

FIG. 2A is a diagrammatical representation of an 
5 electronic bill payment system according to the present 

invention . 

FIG. 2B is a diagrammatical representation of an 
electronic bill payment system according to the present 
invention . 

10 FIG. 3 is a flow chart illustrating merchant 

identification in accordance with the present invention. 

FIG. 4 is a block diagram illustrating accesses to the 
merchant database during merchant identification in 
accordance with the present invention. 
15 FIG. 5 is a flow chart illustrating account ranging in 

accordance with the present invention. 

FIG. 6 is a flow chart illustrating account scheming in 
accordance with the present invention. 
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PREFERRED EMBODIMENT (S) OF THE INVENTION 

FIG.l generally depicts a bill payment system including 
consumer systems (i.e., payors) 8, merchant systems (i.e., 
payees) 4, source systems 7, a remittance payment processor 
5 (RPP) 3, merchant bank systems 5, and consumer bank systems 

6. 

A consumer system 8 provides the consumer (i.e. payor) 
with an interface to the RPP 3 via a source system 7 and 
typically would be a personal computer located at the 

10 consumer's residence, but could possibly be another 

electronic device such as a phone or specialized box 
containing bill payment software. A consumer is an 
individual or other entity, e.g., a corporation, for whom 
payments are actually made and whose account will be debited 

15 by the amount of the payment. 

Source systems 7 represent any computer or network of 
computers capable of collecting payment requests from one or 
more consumer systems 8, and may be, for example, a 
CheckFree processing center 7B, a financial institution 
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processing center 7A, or a third party payment processing 
center 7C. 

Merchant systems 4 are computer systems typically owned 
by merchants for carrying out the bill payment process. 
Merchants are the persons or other entities to whom payments 
are made via the bill payment system on behalf of consumers. 
Merchants may include department stores, the phone company, 
the paper boy, a credit card company, as well as other 
persons and entities to whom payments are owed by one or 
more of consumers. Merchants have accounts with merchant 
bank systems 5 to which payments made on behalf of consumers 
are forwarded for deposit. 

Consumer bank systems 6 either physically or 
electronically hold funds on account for consumers. These 
accounts are debited by the amount of any payments made to 
merchants on behalf of the consumers. 

A network 1 connects the above-stated entities making 
communications between them possible. The network may be of 
any type capable of facilitating the flow of information 
among the various entities. It could, for example, be a 

14 
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public telecommunication network, the Internet, or other 
type of communication network. The network 1 may also be 
physically realized as one or more private or public 
networks. For example, in one possible embodiment, consumer 
systems 8 are coupled to a source systems 7 through one 
network and the source coupled to the RPP 3 through another 
separate network. 

FIGS. 2A-2B illustrate an overview of the process flow 
of a bill payment system. As shown in FIG 2A, source 
systems 7A-C collect payment requests from consumer systems 
8A-8C over networks 1A-1C. Typically, each source has its 
own consumer base of subscribed consumers. Thus, Referring 
to Figure 2A, Bank Source System 7A collects payment 
requests from consumer system Al through consumer system AN, 
denoted as consumer systems 8A, where there are N subscribed 
consumers, over network 1A. Similarly, CheckFree Source 
System 7B collects payment requests from consumer system Bl 
through consumer system BM, denoted as consumer systems 8B, 
where there are M subscribed consumers, over network IB. 
Similarly, Third Party Source System 7C collects payment 

15 
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requests from consumer system CI through consumer system CP , 
denoted as consumer systems 8C, where there are P subscribed 
consumers, over network 1C. 

In Figure 2A, each source is depicted as receiving 
payment requests from consumers over its own wide area 
network 1A-1C. However, other network configurations are 
possible. For example, the payment requests could be 
received over a single network, such as the Internet. 
Furthermore, the networks may be private or public (e.g., 
the Internet) . 

A payment request contains payment information for a 
consumer which will include several different types of 
information, such as the consumer account number, the 
merchant name, and the merchant address. 

RPP 3 receives payment requests from each of the 
sources 7A-7C via networks ID- IF. Typically, each source 
collects the payment requests, processes the requests into 
batch files, and transmits the batch files over networks 1D- 
1F. In FIG 2A, each source is depicted as connected to the 
RPP 3 shown in FIG 2B over a wide area network. However, 
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other network configurations are possible including the 
possibility that networks ID- IF are a single network, and 
the networks may be private or public (e.g., the Internet) . 

The RPP 3, as further detailed in Figure 2B, includes a 
memory 16 storing programmed instructions for carrying out 
the functions of the RPP, a processor 17 for executing these 
instructions, and a merchant database 18 storing information 
associated with the merchants 4. 

RPP 3 includes an input port 10 which accepts and 
collects together the payment requests from each of the 
respective sources 7. Preferably, RPP 3 also includes a 
normalization unit 9 which accepts the collected payment 
requests from input port 10, each payment request in a 
particular source's format and automatically converts the 
received format to a format compatible to the RPP 3. Thus, 
each source does not have to alter its own formatting or 
procedures in order to have payment requests processed by 
the RPP 3. 
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The RPP 3 processes the received payment information 
from the payment requests, and passes payment instructions 
to a merchant payment processing system 25 which processes 
the payment instructions in processor 24 in accordance with 
programmed instructions on memory 23, and makes payments to 
merchant systems 4 either directly or indirectly. It should 
be understood that the merchant payment processing system 2 5 
could be multiple systems which respectively reside with 
each source 7, a single system (as shown) which resides with 
the RPP 3 or as a separate stand-alone system controlled by 
an entirely separate entity connected to the RPP 3 by a 
network. Hence each source processing system 7 collects 
payment requests made by consumers in its consumer base and 
the one or more merchant payment systems 25 makes payments 
on behalf of these consumers 8 in accordance with payment 
directions from the centralized RPP 3. 

Payment is made from the payment processor 25 to 
merchant system 4 or merchant bank system 5 electronically 
through networks 1G-1J, or alternately can be transmitted by 
paper through checks 32 and drafts 34. Payment advice 

"L 8 
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reflecting the payment can also be directly sent by network 
1G to merchant system 4. The payment information is 
presented to the applicable merchant electronically in a 
form that the merchant system 4 can process to update the 
5 merchant's records. 

As shown in Figure 2B, one possible mode of payment to 
a merchant via merchant bank 5 is electronic funds transfer 
through the Federal Reserve Automated Clearing House (ACH) 
Network 1H. Another electronic payment avenue is through 
10 the MasterCard RPS Network 1J. Additionally, payment can 

also be made non-electronically to a merchant by a check 32 
or a draft 34 printed on laser printer 28. Payment advice 
can alternatively be delivered through Fax 22 or through the 
telephone network II. Thus, by the above described process, 
15 the bill payment system of the present invention pays bills 

to merchants according to payment requests received by 
customers through multiple sources. 

Now taking a closer look at the RPP processor 17, the 
RPP stores or processes several different record types 
20 necessary to the bill payment process. A merchant record 
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contains all necessary information needed to forward a 
payment. This includes a merchant name, address, and zip 
code. A consumer record includes a consumer name, address, 
zip code, and consumer account number. A payment record 
will contain information related to payment, including payee 
identification, consumer identification, and the dollar 
amount of the transaction. The merchant records are stored 
in a merchant database 18. All other records as well as 
programmed instructions which direct the operation of the 
RPP are stored in a memory 16. The memory 16 could also 
store the merchant database 18 if desired. 

After receiving payment requests from sources 7, the 
RPP 3 periodically initiates a payment cycle 2 0 which 
process the records to generate information which will be 
used by the payment processing system 25 to credit merchant 
accounts and advise the merchant systems of the payments. 
The processing flow of the billing cycle contains, in 
addition to other processes, three particularly important 
processes necessary for successful processing of each 
payment request. These processes are merchant 

20 
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identification 19a, account ranging 19b, and account 
scheming 19c, typically performed in this order. In the 
first step of processing a payment request, the processor 17 
attempts to identify a merchant in the merchant database 18 
5 based on information in the payment request. In the second 

step, the processor 17 will attempt to determine a 
remittance center of the merchant to which the payment 
and/or payment information is to be sent. If a candidate 
remittance center is identified, the system enters the third 

10 stage of processing, account scheming. In account scheming, 

the processor 17 attempts to normalize a user account with a 
merchant according to the merchant's rules. If account 
scheming fails, the system will return to the account 
ranging process to attempt to identify another candidate 

15 remittance center, and from there, again into account 

scheming . 

Although the above described payment cycle is a 
preferable embodiment of the RPP, a payment cycle can 
include merchant identification 19a, account ranging 19b, 
20 and/or 19c, in any order or combination. In addition, these 
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processes may be performed independently, and could be 
performed individually outside the RPP. These three 
processes will now be described in further detail herein 
referring to FIGS 3-6. 
5 FIG. 3 illustrates merchant identification. Using 

merchant identification, the RPP 3 is able 'to retrieve the 
correct merchant record from merchant database 18 based on a 
consumer's payment request submitted with possibly erroneous 
merchant name and address information, e.g., street address, 
10 city, state, zip code. It has been observed that data entry 

operators will often make errors in the merchant's street 
address and zip code. The RPP 3 is capable of mapping the 
mangled merchant information supplied in the payment request 
into the proper merchant record in the merchant database 18 
15 notwithstanding the errors in the merchant information. 

Merchant identification as described herein, can be used in 
any implementation where merchant information is likely to 
contain errors and must be mapped into an existing merchant 
record in the merchant database. 
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RPP 3 initiates merchant identification by step 6 0 
which retrieves a payment record from one of the payment 
records previously submitted by the source 7. At step 62, 
the RPP first attempts to retrieve a merchant record from 
the merchant database 18 by matching the merchant id 
included in the payment record against the records of the 
merchant database 18. If there is a match, then at step 63 
processing of the payment record continues to the payment 
directions stage 64 . The payment directions stage is where 
the RPP determines where to send payments. This stage 
includes account ranging discussed below which determines 
the remittance center to which payment gets sent. If there 
is no match at step 63, the RPP continues to step 65. At 
step 65, the RPP maps the merchant's merchant name and 
address, excluding the provided street address and zip code, 
into an eleven digit zip code. That is, the RPP produces an 
eleven digit zip code based on merchant name, city, and 
state in the payment information. In order to avail the 
merchant information which the inventors have determined to 
be mostly likely to contain errors, the received merchant 

23 
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street address and zip code are not considered. Hence, in 
step 65 the RPP 3 identifies an eleven digit zip code based 
only on the merchant's name, city, and state. 

Step 65 of merchant identification uses the indexing 
structure shown in Figure 4 to access one or more records 
from the merchant database 18. In step 65, referring to 
FIG. 4, the RPP 3 forms an 11 digit zip code index 82 and 
compares this index to index 84 in order to retrieve a 
merchant record in merchant database 18. It may be possible 
that there is more than one merchant at a location 
identified by an eleven digit zip code. For example, there 
could be a remittance processing center on the floor of the 
building identified by the eleven digit zip code which 
handles payments for several merchants 4. In such a case, 
the RPP differentiates the correct merchant record from 
other possibly correct merchant records associated with the 
same eleven digit zip code by, after identifying merchant 
records indexed to the same eleven digit zip code, comparing 
some portion of the merchant's name, e.g., the first five 
characters with the characters of each merchant's name which 
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has been combined with the application zip code in the 
merchant index. The RPP 3 is thereby able to uniquely 
identify the proper merchant record. 

If step 65 identifies a unique merchant record then 
there is an exact match and at step 66 processing continues 
to step 64. However, if step 65 retrieves more than one 
merchant forming a group of records 86, (see FIG 4) then at 
step 66 processing continues to step 67. At step 67, the 
RPP 3 will attempt to match one or more characters of the 
merchant's name 83 against the records 86 to identify a 
merchant record. If a match is found, processing continues 
at step 68 to the payment directions stage 64. If there is 
no match, then at step 68 the program will continue to step 
69 where the RPP will handle the unmanaged merchant. If 
there is no merchant, the system may have provisions at step 
69 for adding the merchant to the merchant database 18. 

FIG. 5 illustrates a payment direction stage, as 
performed in the preferred embodiment of the present 
invention, in which the RPP attempts to determine a 
remittance center to which payment is sent. The RPP 
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determines a remittance center based on one or more of the 
following identification rules: 1) length of account number, 
2) merchant zip code, 3) merchant name, and 4) account 
ranging. Each rule has in common that it identifies the 
5 remittance center based on some factor of the payment 

information. 

In Figure 5, the RPP 3 processes the payment record 
presented in step 51 to determine one of a plurality of 
remittance centers associated with the applicable merchant 

10 in which to make payment. In step 53, the RPP chooses one 

of the above-mentioned four rules and at step 55 attempts to 
identify a remittance center. If a remittance center is 
found at step 56, then the RPP directs payment to that 
remittance center 58. If the RPP is unsuccessful in 

15 determining a remittance center, the RPP cycles back to step 

53 and picks a new rule for identification. By this 
process, the system cycles through all combinations of rules 
that identify remittance centers for the merchant. 
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In account ranging, the correct remittance center is 
determined based on some characteristic of the consumer's 
account number. Typically a large merchant, such as credit 
card company will have multiple remittance centers to which 
5 respective consumer payments must be submitted. The payment 

record contains information which may be used to identify a 
remittance center besides an account number, such as an area 
code of the payor's telephone number. A telephone phone 
utility might include each consumer's area code in the 

10 consumer's account number and require payments from all 

consumers within a particular area code be directed to a 
particular one of multiple remittance centers. A credit 
card company may require that payments from all consumers 
having the same first six digits in their account numbers be 

15 made to the same remittance center . 

The payment direction process illustrated in Figure 5 
is a preferred embodiment for determining payment direction. 
In this embodiment, the payment direction process includes 
account ranging as one of four possible methods of 

20 identifying a remittance center. However, in other 
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embodiments, account ranging may be used in different 
combinations, or independently. 

FIG. 6 illustrates the steps for account scheming. In 
certain cases, the consumer account number received by the 
5 RPP as part of the payment information may contain errors. 

Hence, the RPP has no way of checking the account number 
against a previously stored account number associated with 
the applicable consumer to verify the accuracy of the 
received information . 

10 Using account scheming, the RPP receives, in step 12a, 

the consumer account number as part of the payment record. 
In step 42, the RPP checks to validate the account number. 
Then in step 46, the RPP alters the account number to 
correspond to a format required by a merchant's system 4 for 

15 processing. 

More particularly, the RPP validates and alters the 
consumer account number by storing separate business rules 
for each merchant which identify the expected general format 
for any consumer account number associated with that 

2 0 merchant. These business rules are stored as validation 
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templates 40 in merchant database 18 for each merchant. The 
account number received from the consumer is checked against 
the validation template to validate that the account number 
conforms to the general account number format to which an 
5 account number associated with the applicable merchant must 

conform. For example, the validation template for a 
merchant such as a credit card company may require an 
account number begin with the numbers M3" and be 18 digits 
long. Additionally, for some merchants the validation 

10 template will have check digit requirements. That is, the 

validation template can be used to confirm that the received 
consumer account number conforms to a check digit after 
being run through a specific algorithm. 

In operation, the RPP 3 performs, in accordance with 

15 programmed instructions stored on the memory 16, the 

validation procedure by comparing in step 42 the received 
consumer account number for the applicable merchant received 
in step 12a with the validation template, say 40, for that 
merchant to test the validity of the account number. If 

20 that account number is not valid, the payment directions are 



IPDC:781.1 33500-00004 



29 



Docket No.: 33500-00004 

rejected as not valid in step 43; otherwise, the account 
number is considered valid. 

Once the account number has been validated, it is then 
modified in step 46 so as to conform to alteration rules 44 
5 for the applicable merchant. The alteration rules 44 are 

also stored in database 18. The alteration rules 44 relate 
to the format of the consumer's account number in which the 
applicable merchant system requires to process a consumer's 
payment. Typically, alteration rules would specify an 
10 altered account number which includes a portion of a payor's 



name with the account number, a portion of the payor's 



address with the account number, or a portion of the payor's 



zip code with the account number. Alteration by the RPP 3 



involves notifying the received account number which will be 



15 



furnished, along with payment, to the merchant. For 



instance, some merchant systems require that the consumer's 



account number always end in "12 0 



n 



Hence, in such a case, 



the RPP 3, in accordance with programmed instructions stored 



on the memory 16, modifies the received account number to 



20 



append w 12 0" to the end of the alpha-numeric sequence of the 
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received account number. Once the account number has been 
modified so as to conform to the format required by the 
merchant system, the altered account number 47 is then 
transmitted from the RPP 3 to the merchant 4 via the network 
5 1, along with the payment, in step 48. 

It will also be recognized by those skilled in the art 
that, while the invention has been described above in terms 
iQ of one or more preferred embodiments, it is not limited 

^ thereto. Various features and aspects of the above 

:;g 10 described invention may be used individually or jointly. 

Further, although the invention has been described in the 
context of its implementation in a particular environment 
\f% and for particular purposes, e.g. a bill payment system, 

those skilled in the art will recognize that its usefulness 
15 is not limited thereto and that the present invention can be 

beneficially utilized in any number of environments and 
implementations. Accordingly, the claims set forth below 
should be construed in view of the full breadth and spirit 
of the invention as disclosed herein. 
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The present invention is not to be limited in scope by 
the specific embodiments described herein . Indeed, various 
modifications of the present invention, in addition to those 
described herein, will be apparent to those of skill in the 
5 art from the foregoing description and accompanying 

drawings. Thus, such modifications are intended to fall 
within the scope of the appended claims . 
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CLAIMS 

What is claimed is: 

1. A method for electronically processing bill payment 
requests , comprising the steps of : 

receiving respective sets of payment requests 
electronically from a plurality of independent sources, each 
5 set of payment requests corresponding to an associated set 

of payors requesting payments to a plurality of payees; and 

processing the payment requests at a single remittance 
processing system having a database including payee 
information for each of the plurality of payees to generate 
10 payment directions for paying the plurality of payees in 

accordance with the processed payment requests. 

2* The method of claim 1, wherein: 

a first of the respective sets of payment requests is 
received in a first format; 
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a second of the respective sets of payment requests is 
received in a second format, different from the first 
format ; and 

processing includes normalizing the first and the 
second respective payment requests to correspond to a third 
format and generating the payment directions based upon the 
normalized first and second respective payment requests. 

3. The method of claim 1, wherein: 

a first of the respective sets of payment requests is 
received in a first format; and 

processing includes normalizing the first respective 
payment requests to correspond to a normalized format and 
generating the payment directions based upon the normalized 
first respective payment requests . 

4. The method of claim 1, wherein each of the 
respective sets of payment requests from payors is received 
as a batch file. 
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5. The method of claim 1, further comprising the step 

of: 

performing one of electronically crediting a bank 
account of the payee and generating a check payable to the 
5 payee in accordance with the payment directions. 



6. The method of claim l, further comprising the steps 

of: 

generating a respective payment advice for each of the 
plurality of payees in accordance with the payment 
5 directions**; and 

electronically transmitting the payment advice to each 
of the plurality of payees. 



7. The method of claim 1, wherein each of the received 
payment requests includes payor payment information, and 
further comprising the steps of: 

processing the payor payment information other 
5 than a received zip code, to identify an eleven digit zip 

code for the payee to be paid; and 
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accessing the database to locate the payee 
information corresponding to the eleven digit zip code. 

8. The method of claim 7, wherein: 

the payor payment information includes a name of 
the payee to be paid; and 

the database is accessed to locate the payee 
5 information which also corresponds to a payee name. 

9. The method of claim 7, wherein: 

the payment information includes an address 
of the payee to be paid; and 

further comprises the step of processing a 
5 portion of the address to identify the payee to be paid. 

10. The method of claim 7, wherein: 

the payment information includes a city and a 
state associated with a payee to be paid; and 
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further comprises the step of processing a 
5 portion of the city and the state to identify a payee to be 

paid. 

11. The method of claim 1, wherein a first of the 
plurality of payees has a plurality of payment remittance 
centers and a first of the payment requests includes 
information identifying a payor account number with the 

5 first payee, and further comprising the steps of: 

processing the account number to select one of the 
plurality remittance centers; and 

directing payment to the one remittance center. 

12. The method of claim 11, wherein the processing of 
the account number includes identifying one or more 
alphanumeric characters representing the one remittance 
center . 
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13. The method of claim 1, wherein each of the payment 
requests includes a payor's account number with a payee, and 
further comprising the steps of: 

storing alteration rules corresponding to a payee 
5 account number format; and 

transforming the account number included in one of 
the payment requests into an altered account number 
according to the alteration rules. 

14. The method of claim 13, further comprising the 
step of: 

transmitting the altered account number to the 
payee to notify a payee of a payment based on the payment 
5 directions. 

15. The method of claim 13, further comprising a step 

of: 

storing validation rules corresponding to payee 
values for fields of the account number; and 
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5 determining if the received account number 

conforms with the validation rules. 

16. The method of claim 13, wherein: 

the altered account number includes a portion of 
the payor's name. 

17. The method of claim 13, wherein: 

the altered account number includes a portion of 
the payor's address. 

18. The method of claim 13, wherein: 

the altered account number includes a portion of 
the payor's zip code. 

19. An electronic bill payment system for processing 
payment requests, comprising: 

an input port for receiving payor payment requests from 
a plurality of separate sources; 
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5 a database configured to store records associated with 

a plurality of payees; and 

a processor for processing the payment requests to 
generate payment directions for paying the plurality of 
payees in accordance with the received payment requests and 
10 the records stored in the database associated with the 

plurality of payees. 

20. The system of claim 19, wherein the input port 
receives a respective batch file from each of the plurality 
of sources, each respective batch file containing payment 
requests from payors subscribed to the source. 

21. The system of claim 19, wherein: 

the payment requests from each of the plurality of 
separate sources are respectively in different formats; and 

the processor is further configured to normalize the 
5 payment requests from each source to correspond to a common 

format prior to producing the payment directions. 
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22* The system of claim 19, further comprising: 
a merchant payment unit for paying the payees based on 
the payment directions by performing one of electronically 
crediting an account of the payee with a financial 
5 institution and generating a check or draft payable to the 

payee . 

23. The system of claim 19, wherein the processor 
generates payment advice to the plurality of payees 
corresponding to the payment directions. 

24. The system of claim 23, wherein the payment advice 
is in a form electronically readable by the payee's system. 

25. The system of claim 19, wherein each of the 
payment requests includes payment information; and 

the processor is further configured to process the 
payment information, excluding zip code information, to 
5 produce an eleven digit zip code associated with the payee. 
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26. The system of claim 25, wherein the processor is 
further configured to retrieve the records corresponding t. 
the eleven digit zip code from the database. 



27. The system of claim 25, wherein the processor is 
further configured to direct a payment to the payee in 
accordance with the payment directions. 



28. The system of claim 19, wherein: 

one of the payor requests a payment to one of the 
plurality of payees having a plurality of payment remittance 
centers, the one request including a payor account number 
5 with the one payee; and 

the processor is further configured to process the 
account number to identify a single payment remittance 
center of the plurality of payment remittance centers, and 
to generate the payment directions to direct payment to the 
0 single payment remittance center. 
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29. The system of claim 28, wherein the processor is 
further configured to identify information in the account 
number which corresponds to the single payment remittance 
center and to identify the single payment remittance center 
based upon the identified information. 



30. The system of claim 29, wherein the identified 
information of the account number includes one or more 
alphanumeric characters identifying a single remittance 
center. 



31. The system of claim 19, further comprising: 

a storage device configured to store validation 
rules corresponding to values for fields of payee account 
numbers and alteration rules corresponding to a payee 
account number format; wherein the payment requests include 
payor account numbers and the processor is further 
configured to: 

verify that the account numbers conform to 
the stored validation rules, 
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-° alter the account numbers according to the 

stored alteration rules, and 

generate the payment directions to include 
the altered account number. 

32. The system of claim 31, wherein: 

the altered account number includes a portion of the 
payor's name. 

33. The system of claim 31, wherein: 

the altered account number includes a portion of the 
payor's address. 

34. The system of claim 31, wherein: 

the altered account number includes a portion of the 
payor's zip code. 

35. A system for processing payment information, 
comprising : 

one or more networks; 
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a plurality of source stations, coupled to the 
networks, each source station configured to collect payment 
requests, each request containing payment information, 
including a payee name, payee address data, and a payor 
account number with a payee; and 

a centralized remittance station, coupled to the 
networks, having a payee database, configured to receive the 
payment information from at least one of the source stations 
via at least one of the networks, and process the payment 
information to produce payment directions for paying a payee 
to be paid selected from the payee database. 

36. The system of claim 35, wherein: 

the centralized remittance station, coupled to the 
networks, is configured to receive the payment information 
from one of the plurality of source stations via the 
networks, process the payment information to produce an 
eleven digit zip code for the payee, and access the database 
to locate a payee record corresponding to the eleven digit 
zip code. 
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37. The system of claim 36, wherein: 

the data base is accessed using a portion of a 
payee name and the eleven digit zip code to access the payee 
record; and 

the payee record further corresponds to the 
portion of the payee name. 



38. The method of claim 37, wherein: 

the access step includes comparing the portion of 
the payee name with a payee name in the payee record in the 
database . 



39. The system of claim 35, further comprising a 
database of alteration rules indicating a format for payee 
account numbers; 

wherein the centralized remittance station 
transforms the payor account number into an altered payor 
account number according to the alteration rules. 
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40. The system of claim 35, wherein the payee has a 
plurality of remittance centers and the centralized 
remittance station is further configured to process the 
account number to identify a single remittance center of the 
plurality of remittance centers, and to direct a payment, 
including the altered payor account number, to the single 
remittance center. 
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ABSTRACT OF THE DISCLOSURE 

A method and apparatus for electronically processing 
bill payment requests where respective sets of payment 
requests are received electronically from a plurality of 
independent sources, each set of payment requests 
corresponding to an associated set of payors requesting 
payments to a plurality of payees. The payment requests ar 
processed at a single remittance processing system having a 
database including payee information for each of the 
plurality of payees to generate payment directions for 
paying the plurality of payees in accordance with the 
processed payment requests. 
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